!!! NOTE TO REVIEWERS !!!

Please only review the docs listed in How has this been tested? section.

When this PR is reviewed, it will be merged into #4756, where all of the changes will be reviewed before merging into main.

Please place any other feedback in #4756

Description

Improving the accessibility documentation of components.

Related issue(s)

• [DO NOT MERGE]: accessibility docs #4756

Motivation and context

Documentation should provide more information and examples that demonstrate how to use the components accessibly.

How has this been tested?

<sp-icon>

Review icon docs

• Are the examples accessible?
• Do the docs examples and text provide information on how to use the component accessibly?
• If the component is to be used in the context of another component, do the examples include how that component is used accessibly in that context?
• Are the docs headings logical and consistent across these components? (1)

<sp-icons>

Review icons docs

• Are the examples accessible?
• Do the docs examples and text provide information on how to use the component accessibly?
• If the component is to be used in the context of another component, do the examples include how that component is used accessibly in that context?
• Are the docs headings logical and consistent across these components? (1)

<sp-iconset>

Review iconset docs

• Are the examples accessible?
• Do the docs examples and text provide information on how to use the component accessibly?
• If the component is to be used in the context of another component, do the examples include how that component is used accessibly in that context?
• Are the docs headings logical and consistent across these components? (1)

<sp-icons-ui>

Review icons-ui docs

• Are the examples accessible?
• Do the docs examples and text provide information on how to use the component accessibly?
• If the component is to be used in the context of another component, do the examples include how that component is used accessibly in that context?
• Are the docs headings logical and consistent across these components? (1)

<sp-icons-workflow>

Review icons-workflow docs

• Are the examples accessible?
• Do the docs examples and text provide information on how to use the component accessibly?
• If the component is to be used in the context of another component, do the examples include how that component is used accessibly in that context?
• Are the docs headings logical and consistent across these components? (1)

Developing a Component Guide

• Does the guide for developing a component provide enough information to create accessible, consistent component docs? (1)

1. You can use the WAVE browser extension's Structure tab to review heading structure.

Font sizes

• Are the above component document font sizes consistent with the following design recommendations?
  • h1: heading XXL, serif, heavy
  • h2: heading L, sans-serif
  • h3: heading M, sans-serif
  • h4: heading S, sans-serif
  • h5: detail L
  • body: body M, sans-serif

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Chore (minor updates related to the tooling or maintenance of the repository, does not impact compiled assets)

Checklist

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• If my change required a change to the documentation, I have updated the documentation in this pull request.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes. N/A
• All new and existing tests passed.
• I have reviewed at the Accessibility Practices for this feature, see: Aria Practices

Best practices

This repository uses conventional commit syntax for each commit message; note that the GitHub UI does not use this by default so be cautious when accepting suggested changes. Avoid the "Update branch" button on the pull request and opt instead for rebasing your branch against main.